METHOD TO PROVIDE AUTHENTICABLE TIME AND LOCATION INDICATION, RADIO-NAVIGATION SIGNAL RECEIVER TO CO

专利摘要:
method for providing an authenticable time and location indication. a method of providing an authenticable time and location indication using a radio navigation signal receiver which comprises receiving radio navigation signals transmitted from a plurality of radio navigation signal sources, at least some of the radio signals - navigation containing one or more cryptographic tokens protected by encryption, the cryptographic tokens being updated periodically. the receiver retrieves, by decryption, the cryptographic tokens of the radio navigation signals that contain them. the receiver then determines the positioning data, which represents your geographic position and time, based on the received radio navigation signals. the receiver generates a digital authentication code using a cryptographic function having at least the positioning data and the retrieved cryptographic tokens as inputs, and produces a data package including a first part 2 that contains the positioning data and a second part 2 that contains the digital authentication code.
公开号:BR112012031598B1
申请号:R112012031598-6
申请日:2011-05-31
公开日:2021-04-06
发明作者:Olivier Chassagne
申请人:The European Union, Represented By The European Commission；
IPC主号:

专利说明:

[0001] The present invention generally relates to the authentication of positioning data. In particular, the invention relates to the provision of an authenticable time and location indication, for example, as a digital recording of time and location attached to a document or other data, using a radio navigation signal receiver. Another aspect of the invention relates to the authentication of positioning data, that is, the process of deciding whether an alleged time and location indication is authentic or not. Fundamentals of Technique
[0002] Safe radio navigation, particularly satellite navigation, tomorrow will be just as important and vital as the secure Internet is today. However, many of the threats to satellite navigation cannot be prevented or combated through current technologies, at least for mass-market civilian applications.
[0003] There are a number of positioning applications, where a user's true position at any given time needs to be known with a high degree of positioning certainty and confidence. Such applications include, for example, fleet management, road, toll, geographic delimitation, virtual website tokens, services based on safety-critical location, "pay-as-you drive" car insurance scheme, etc. In other applications, it may be necessary to establish whether a user was in possession of certain data at a specific time and in a certain location.
[0004] User acceptance and market penetration of these applications will depend to a large extent on their reliability and confidence in the integrity and robustness of the services provided. In this context, users of the invention include both users of the receiver, whose positions are defined based on radio navigation signals from the radio navigation system (usually referred to as "end users") and service providers, that use positioning data received from end users. These service providers can be referred to as third party service providers, as they are usually different from the positioning system operator.
[0005] End users, on the one hand, usually want to be sure of the authenticity of the radio navigation signal source. This concern is linked to the concept designated as signal authentication in space (SIS).
[0006] Third party service providers, on the other hand, usually want to have a guarantee that each positioning data they receive from their end users (subscribers) actually corresponds to the position of the end user at the time indicated. This implies, first, that the positioning data has been computed based on the true radio-navigation signals and, second, that it has not been tampered with, that is, modified from falsified in order to provide a position or a wrong time.
[0007] The concept related to positioning data authentication declared by end users or transmitted by their radio navigation signal receivers will be referred to later for position-speed-time authentication (PVT). PVT stands for position-speed-time, the most common set of data calculated by positioning receivers.
[0008] International Patent Application WO 2009090515 solves the problem of positioning data authentication in the context of the infrastructure-free road toll. The charging system in an automated toll road system is based on the distance traveled, time and / or date of travel, location (geographical area) and / or characteristics of the vehicle (length, cylinder capacity, fuel consumption, C02 emissions , etc.). WO 2009090515 aims to prevent a so-called "false GPS attack", that is, to provide false GPS data to the toll institution, in order to reduce tolls to be paid. This is done by providing the toll institution with readings from vehicle condition sensors (speed, steering angle, travel distance, local weather, etc.). The toll institution will then be the GPS data with the vehicle's condition data for the purpose of authenticating or invalidating the GPS data.
[0009] International Patent Application WO 2009/001294 also refers to fraud prevention and detection in the context of a road toll system. The user's receiver retrieves the positioning data, receiving processing, navigation signals and low conversion. The toll institution is then provided with the decoded position data, as well as raw data (samples of converted low navigation signals) and can then verify that the sample of raw data corresponds to what is expected at certain location and time indicated by the transmitted position information.
[0010] A similar method is followed by US Patent 5,754,657, which discloses an authentication or validation method in which the receiver, whose position is to be validated or invalidated, transmits an "increased data signal", comprising radio navigation signal data gross, as well as the stated position and time. The increased data signal is transmitted to a central station, which essentially checks whether the raw data is consistent with the stated position and time, as well as with the signals transmitted by the satellites.
[0011] Another interesting solution is proposed in the article “Signal Authentication - A Secure Civil GNSS for Today”, by Sherman Lo et al., Published in the September / October 2009 issue of InsideGNSS. The authentication method disclosed in this article is based on the fact that the L1 GPS frequency carries AC code and P (Y) code signals (encrypted), transmitted in phase quadrature. The user's receiver transmits its computed position and time together with a snapshot of P (Y) (gross) code signals to an authentication authority. The method exploits the P (Y) code sequence received at a first location (the location of a receiver, whose position is to be authenticated) is identical to the P (Y) code sequence received at a second location (the location of a reference receiver under the control of the authentication authority), if the difference in signal times of the satellite receiver is taken into account. The presence of a correlation peak in P (Y) (raw) code sequences recorded at both locations establishes the authenticity of the CA code signal (if it is assumed that both receivers are not simultaneously within the invading counterfeit receiving range) . Aspects of the method disclosed in the article were also the subject of US Patent Applications 2009/0195443 and US 2009/0195354.
[0012] Basically, there are three different types of threats to the positioning data integrity:
[0013] Threats to the integrity of signals-in-space (for example, in interference, forgery and detection by radio beacon). These are threats that occur "upstream" from the computation of positioning data. Interference is the emission of a radio frequency signal or noise with sufficient power and with specific characteristics, in order to supplant the navigation signals within the neighborhood of the interference device. Interference has the effect of preventing positioning receivers from acquiring and controlling navigation signals within an area, the surface of which depends on the emission power of the interference device. The positioning receiver subjected to an interference attack is rendered unable to produce PVT data or can only produce affected PVT data of high uncertainty (exhibiting a wide range of error). All signals, whether encrypted or not, can be compressed. Interference devices are available on the market at low prices (less than € 100). The interference device can be detected by receivers equipped with ad hoc devices and positioning algorithms. Interference is illegal activity in most countries. Counterfeiting is the transmission of signals, resembling positioning signals by a simulator located on the ground, with the purpose of deceiving positioning receivers. Counterfeiting is illegal in most countries. Counterfeiters cannot, in principle, simulate encrypted signals (for example, the current GPS P (Y) code, the future GPS M code, or the future Galileo CS and PRS codes) unless they can break the code encryption navigation, which is very unlikely. Counterfeiters are not yet readily available on the market, but can be easily produced by receiver manufacturers by persons skilled in the art. It is expected that counterfeiters will be available in the market for some years at affordable prices, between about € 100 and € 1000. The detection by radio beacon is the reception and retransmission of real navigation signals, with or without a delay. The original signals are read using a high quality antenna, delayed and then retransmitted by a transmitter, so that the delay signals lead to the computation of a wrong position. Unlike counterfeiting, radio beacon detection can, under certain conditions, also mislead positioning receivers by working with encrypted navigation signals.
[0014] Threats to PVT computing (for example, hardware or software failures, worms and / or viruses altering the computing process).
[0015] Threats to the integrity of PVT after it has been computerized (tampering with computerized PVT) or after it has allegedly been computerized (in the case of completely composite positioning data). A PVT, for example, could be intercepted and replaced by a false PVT in transmission over telecommunications networks between the user's receiver and the third-party service provider. This could also be modified when stored on electronic supports, for example, within the service facilities of the provider. Technical problem
[0016] There are two main concepts of authentication that occur in the context of radio navigation. The first one is hereinafter referred to as independent SIS authentication, where "SIS" is the acronym for signal-in space, that is, the signal that arrives at the receiver. Autonomous SIS authentication allows a user of a GNSS receiver, or the receiver, to verify that the signals used to calculate a position are those of a given GNSS constellation (and not signals transmitted by a ground-based device or carried by the air) and has been computed by a reliable algorithm. The independent SIS authentication thus aims to authenticate the sources of radio navigation signals. Independent SIS authentication addresses the following two questions, which each user of the GNSS receiver is concerned with: Is the receiver being falsified Is the receiver's software reliable
[0017] The second concept of authentication is hereinafter referred to as remote PVT authentication. This serves third parties wanting to check the positions declared by users. Remote PVT authentication allows a third party to validate that the positioning of data produced by a radio navigation receiver, whether integrated with other sensors, or not, is not tampered with, that is, it is not modified or falsified for the purpose to provide, for example, a wrong position, a wrong speed and / or a wrong time. The concept of remote PVT authentication assesses the degree of reliability of the already registered positioning data and the source that has produced this positioning data.
[0018] Remote PVT authentication addresses the following issues that a positioning data recipient is concerned with:
[0019] Remote PVT authentication addresses the following issues that a positioning data recipient is concerned with: Is this positioning data reliable Does the positioning data come from the recipient alleged to have produced the same data
[0020] End-to-end position authentication is the conjunction, or combination, autonomous SIS authentication and remote PVT authentication in a single application. This is exactly what the present example aims at.
[0021] It may be worth emphasizing, again, as it distinguishes between independent SIS authentication and remote PVT authentication.
[0022] Independent SIS authentication ensures that the signals read by a radio navigation receiver are those transmitted by a constellation of GNSS - or a constellation of pseudo-satellites - and not those transmitted by a malevolent device. Independent SIS authentication is especially important for the end user. In other words, independent SIS authentication is what users of GNSS receivers want. This answers the question whether the user of a GNSS receiver can trust the positioning provided by his receiver. Remote PVT authentication ensures that positioning data has not been tampered with since the first time that positioning data has been computed. Remote PVT authentication matters to third parties who are in a contractual relationship with users of radio navigation receivers or who have authority to control users. It does not matter to the user of the radio navigation receiver. In other words, remote PVT authentication is what third parties want. This answers the question whether a third party can trust the positioning data sent by a user.
[0023] In addition, independent SIS authentication can be used to provide user information about the level of confidence associated with positioning accuracy, especially in situations where local effects, such as different routes, are interfering SIS measurements.
[0024] It can be noted that independent SIS authentication alone is of no value to third parties in search of reliable positioning data, as positioning data provided to third parties may have been forged. In addition, remote PVT authentication alone is less interesting without independent SIS authentication: if the authenticity of the signals used to compute the positioning data cannot be verified, the positioning data may have been computed based on false signals radio navigation. Even in the absence of any changes to the positioning data, which cannot be completely reliable.
[0025] It may be further noted that it is easier to trust a "trusted authority" than two authorities. In other words, while it is conceivable in theory to have two different entities, the first providing independent SIS authentication and the second providing remote PVT authentication. However, in practice, the coexistence of two distinct entities makes the processes much more complex for the following reason: both depend on the same radio navigation receiver and on their tamper-proof nature. In addition, if two different entities were to provide independent SIS authentication and remote PVT authentication, respectively, the receiver would maintain a weak link in the chain of trust. In this case, there is always a risk of an indirect attack on the interface, that is, inside the receiver. For example, people willing to cheat could put a PVT simulator between the two applications. Such an attack is impossible in the application described below.
[0026] It is an objective of the present invention to provide an authenticating computation method of positioning data, i.e., authenticity that can be verified later by a positioning data authentication authority. This objective is achieved by a method as claimed in claim 1. General description of the invention
[0027] The present invention can be implemented in the context of any type of Global Navigation Satellite System (GNSS) or a radio navigation system using a constellation of pseudo-satellites. A fundamental aspect of the invention is that radio navigation signal sources broadcast radio navigation signals (satellites or pseudo-satellites) that contain a cryptographic token within their data content. Cryptographic tokens can be thought of as pseudo-random numbers or keys (for example, in the form of a binary string) that are updated from time to time under the control of an authentication authority. These are unpredictable in the sense that it is probably impossible to derive future cryptographic tokens from the history of cryptographic tokens, that is, some or all of those previously transmitted. In this sense, cryptographic tokens can be considered as moments of cryptography ("numbers used once") -even if a specific value of the cryptographic token may reappear (sometimes unpredictable).
[0028] Cryptographic tokens are used as crypto variables by radio navigation signal receivers dedicated to digitally recording and / or encrypting the computerized positioning solution, that is, the computerized geographical position and time based on the received radio navigation signals. The receivers then produce a data package comprising a first and a second part, the first of which includes the positioning data (the positioning solution) and a public receiver identifier, and the second part containing a compilation (value of hash) or an encapsulation (encryption) of the positioning solution. The package data can be stored at the receiver and / or communicated to other entities, for example, a third party service provider.
[0029] In the present context, the term "data positioning" is understood to mean time and geographical position (in 2D, for example, as longitude and latitude, or in 3D, for example, as longitude, latitude and altitude), possibly in combination with one or more of the following data types: speed (vector); acceleration (vector); variation (vector), that is, the rate of (vector of) variation of the acceleration; position (vector),
[0030] accuracy and data integrity such as the dimensions of a trust box centered on the computerized time and geographical position, indicating which part of space-time contains the current time and the geographical position, with a determined probability (confidence level).
[0031] Data packets can then be submitted to the authentication authority, which checks whether the time and geographical position indicated on the data pack are consistent with the compilation and / or the ciphertext. For this purpose, the authentication authority maintains an archive of the cryptographic tokens that have been transmitted or uses an algorithm to retrieve the cryptographic tokens corresponding to the stated position and time. Depending on the result of the consistency check, the authentication authority can then establish a certificate that attests to the authenticity of the data packet or indicating whether the consistency check has failed. If the consistency check fails, there is a strong suspicion that the data package has been tampered with or obtained under irregular conditions (for example, under a blockade, counterfeit attack or radio-beacon detection).
[0032] If cryptographic tokens could be easily extracted from the data message of radio navigation signals, it would theoretically be possible for a malicious third party to archive transmitted cryptographic tokens and use these archived tokens for forgery, given a given geographical position and time, a compilation and / or encrypted text and assemble a data package in the correct format. In the absence of new security measures, the forged data package would then possibly be considered authentic by the authenticating authority.
[0033] There are several options for processing this type of extremely difficult attack. To deny access to cryptographic tokens, they are protected by encryption in the transmission of radio navigation signals. To this end, cryptographic tokens can be distributed on secure radio navigation signals. A radio navigation signal is qualified as safe if one of the following conditions is met: the radio navigation signal is encrypted (that is, the signal range code is encrypted) with a state of the art encryption algorithm, or the radio-navigation signal is not encrypted (open signal), but the data message (including cryptographic tokens), which it transmits is encrypted with a state-of-the-art encryption algorithm; or the radio-navigation signal and its data message are encrypted with the same state-of-the-art encryption algorithm or two different encryption algorithms, with two different sets of keys.
[0034] Cryptographic tokens can be common to some or all of the radio navigation signal sources, that is, these signal sources thus transmit the same chronological sequence of cryptographic tokens. Alternatively, each radio navigation signal source can be characterized by a specific cryptographic token. In this alternative option, each radio navigation signal source transmits its own chronological sequence of cryptographic tokens, the token sequences, being mutually distinct between the different signal sources. In this option, the radio navigation signal receiver receives a plurality of cryptographic tokens for each fixed position. The crypto variable used to digitally record and / or encrypt the computerized positioning solution is thus a function of the plurality of cryptographic tokens. In this scenario, the crypto variable depends on the time of the fixed position (when the cryptographic tokens are updated regularly) and on the geographical position (when the radio navigation signal sources in visibility of the receiver depend on its current location). It should be noted that, even in the case where each radio navigation source transmits its individual token sequence, here may be periods when some of the tokens from different sources are accidentally equal in value.
[0035] As another security aspect, access to cryptographic tokens preferably made dependent on using a predetermined type of software and / or hardware from the receiver (eg, a cryptographic module), in particular software and / or hardware from the receiver to the proof adulteration. In this way, the receiver advantageously comprises a security perimeter to perform all critical security operations and to prevent the reading of third party cryptographic tokens. A fingerprint of the receiver's software can be included in the data package to allow the authentication authority to verify that the receiver's software has not been altered. If an invalid fingerprint is provided to him, the authentication authority will issue a software change alert certificate.
[0036] Preferably, the keys that give access to receivers for radio navigation signals (encrypted) and / or cryptographic tokens (preferably in conjunction with the navigation message) are distributed only to receivers that pass a scan of their hardware and / or software, according to a secure communication protocol. The keys to access the cryptographic tokens and / or the key to access the radio navigation signals of preference are periodically changed to ensure that receivers from the security perimeter that has been tampered with do not have long-term access to cryptographic tokens. This makes it much more difficult for an attacker using broken receivers to build an extensive file of the latest cryptographic tokens. In practice, in cases where the keys are updated, when the keys giving access to the radio-navigation signals and / or cryptographic tokens, stored in the receiver, are about to expire, the receiver can establish a secure communication channel with the authority of authentication or prompt the user to do so for the purpose of retrieving subsequent keys.
[0037] Considering that conventional digital signatures are concerned with authenticating the author or the source of a message or a digital document, the invention does not authenticate the recipient user by itself, but can expand the scope of digital signatures with secure information about when and where a digital signature has been produced, provided that the authentication device is configured in accordance with the present invention.
[0038] Several segments of the radio navigation system are concerned with the present invention, such as: the terrestrial segment of the radio navigation system, which is responsible for, among others, synchronizing the satellites and / or pseudo-satellites and preparing the data message to be transmitted to the radio navigation signals; the segment of radio navigation signal sources (satellites and / or pseudo-satellites); in the case of a global satellite navigation system, this is known as the space segment, which normally comprises about 24 to 30 operational satellites in an average Earth orbit in three or six different orbital planes; the user segment comprising radio navigation receivers; the authentication authority, or the authentication authority; where applicable, a telecommunications segment for the transmission of data packets from receivers to geolocalized service providers (data packet network); and a secure telecommunication segment for the distribution of keys that give access to radio navigation signals and / or cryptographic tokens for receivers.
[0039] The applicant reserves the right to direct the claims to the different aspects of the invention separately, possibly in one or more divisions or continuation applications if applicable.
[0040] Turning first to the user segment, an aspect of the invention relates to a method for providing authenticated time and location data using a radio navigation signal receiver. The method comprises receiving radio navigation signals, transmitted from a plurality of radio navigation signal sources (for example, satellites or pseudo-satellites), at least some of these radio navigation signals, containing, in your messages data, one or more cryptographic tokens protected by encryption and updated periodically, preferably under the control of an authentication authority. The receiver retrieves, by decryption, the cryptographic licenses for radio navigation signals. If the radio navigation signals carrying the tokens are encrypted, the receiver gains access to signal data messages using the corresponding key. Likewise, if the cryptographic tokens themselves are encrypted (in an open or encrypted signal), the receiver decrypts them using the appropriate key. The receiver then determines the positioning of data, including its geographical position and time (date and time of day), based on the radio navigation signals received, that is, it performs in a fixed position and determines the time. The receiver generates a digital authentication code, which is a compilation of a cryptographic message, or an encrypted text, or a combination of a compilation and an encrypted text, using a cryptographic function having at least the positioning data and the cryptographic tokens recovered. The receiver then produces a data packet that includes a first part containing the aforementioned positioning data, a public identifier for the receiver (that is, a written marker for the receiver), and a second part containing the authentication code above mentioned digital. Own cryptographic tokens are used to produce the digital authentication code, but are not included in the data package.
[0041] Still in the user segment, another aspect of the invention concerns a radio navigation signal receiver configured to perform this method. For this purpose, the receiver is equipped with suitable hardware and software. One aspect of the invention thus relates to a computer program for a radio navigation signal receiver, comprising instructions, which, when executed by the radio navigation signal receiver, cause it to operate according to the method.
[0042] For example, it can produce the cryptographic function, such as the digital authentication code, a digital compilation in the form of a positioning data hash value and possibly the public receiver identifier, using, as a crypto variable, a cryptographic key that is a function (for example, a concatenation) of at least recovered cryptographic tokens. Alternatively or additionally, the encryption function can encrypt the positioning data and possibly the public receiver identifier using that cryptographic key as a crypto variable.
[0043] It should be noted that, in addition to the positioning data and the public receiver identifier, the encryption function can take complementary data inputs to protect, for example, one or more digital documents, such as digital photos, user identification data , signal integrity data in space, fingerprint receiver software, complementary positioning data, digital signatures, etc. The digital authentication code, in this case, serves to establish that these additional data have been stored or handled by the receiver, at a specific time and in a specific location.
[0044] The invention, therefore, can be used to protect not only the identification of the receiver and the positioning data that they produced, but also, in addition, other identification information or related to the user; and / or any digital document processed by the receiver, such as photos, films; scanned documents, measurement data files.
[0045] Advantageously, additional data to protect can include:
[0046] Identification data, identifying the recipient's user and / or any digital form of administrative authorizations belonging to the user (such as a driver's license, a driver's license, a vehicle registration certificate, a vehicle insurance certificate, digital rights for access to multimedia documents); including printing of program code from the receiver's software; and / or attack alert data; and / or digital data or document produced by a device of a measuring device, a photocopying machine, a camera, a video recorder, etc., equipped with an internal radio navigation signal receiver.
[0047] For the sake of simplicity, to protect the positioning data and the additional option can be designated simply as "data for protection".
[0048] There are several ways in which the cryptographic function can be configured to protect the data it receives as input. For example, the cryptographic function could produce a hash value (summary) of some or all of the data to protect using the cryptographic key as a crypto variable. The cryptographic function could also encrypt some or all of the data to protect, using the cryptographic key. The cryptographic function can thus be configured to output a hash value and / or an encrypted text of the data to be protected. If some of the data to be protected is hashed only (but not encrypted), this data must be included in the first part of the data package as plain text in the same format as when it is used as input for the encryption function (encryption) ), in order to allow the authentication authority to check the consistency of the data in plain text with the hash value. However, if the data is encrypted, it means that it will be possible for the authentication authority to retrieve the original data from the digital authentication code, decryption, it need not be included in the data package necessarily in the same format as when it is used as input for the encryption function (that is, usually in plain text).
[0049] It is worth remembering that the digital authentication code may contain other data in addition to the positioning data and the public receiver identifier. In this case, the authentication authority can confirm that this additional data has been processed by the recipient at a given time in a given location. Another point to note is that the data package can be encrypted (in whole or in part) by the user after it has been produced, for example, in order to protect the user's privacy. The data packet then needs to be decrypted before it is presented for authentication to the authenticating authority, or the latter must be provided with the key to decrypt the data packet, so that the authenticating authority can retrieve non-text content. encrypted and the digital authentication code.
[0050] The encryption key used to cut and / or encrypt the data to be protected preferably comprises a concatenation of cryptographic tokens transmitted through the different radio navigation signal sources. However, the cryptographic key can also be obtained by a more complicated function of cryptographic tokens (including the permutation of mixing the tokens, etc.). The function that is used to generate the token cryptographic key is known only to the authentication authority, which, being asked to authenticate a data packet presented to it, retrieves the cryptographic tokens corresponding to the alleged geographical position and time (from file or using a secret algorithm), in order to reconstruct the cryptographic key used by the receiver's cryptographic function.
[0051] The radio navigation signal receiver may have stored a secret key, referred to in this article as the secret receiver identifier, known to the authentication authority only (the secret key is a "shared secret" of the receiver - not the user - and the authentication authority). This can be stored, for example, inside the receiver by its manufacturer under a license agreement with the authenticating authority. In this case, the function used to generate the cryptographic key can use the receiver's secret identifier as an entry in addition to the cryptographic tokens. The encryption key, for example, could be a concatenation of cryptographic tokens and all or part of the secret key. This option is especially advantageous to ensure a constant length of cryptographic keys in the case of a plurality of cryptographic tokens, given that the number of sources with receiver visibility can vary in time and depending on the location. In the case of a GNSS, for example, the number of radio-navigation satellites in view of the receiver is actually not constant. Therefore, if the cryptographic key were obtained, for example, by concatenating only the cryptographic tokens, the length of the key varies and then, it would be the strength of the cryptographic key and the robustness of the authentication code. The cryptographic key thus preferably has a fixed length (number of bits), with the chosen length sufficient for robust encryption. In this way, the receiver advantageously uses a part of the receiver's secret identifier to fill any vacant bits, that is, to arrive at the predefined length of the cryptographic key.
[0052] Preferably, in the case of a plurality of cryptographic tokens, the data pack contains in its first and second parts data identifying the signal sources, transmitting the cryptographic tokens used by the receiver to calculate the cryptographic key (signal source identification data ). This option is especially preferred, since the declared time and location are not sufficient in all instances for the authentication authority to determine which cryptographic tokens have actually been retrieved by the radio navigation receiver. In fact, time and location information allows you to establish which signal sources were theoretically visible to the receiver. The reception of radio navigation signals from some of these sources, however, could have been avoided (for example, due to masking). In the absence of any other indication as to which cryptographic tokens actually used by the recipient, the authentication authority would have to check many of the theoretically possible combinations of cryptographic tokens until it finds the one that was used to generate the cryptographic key. On the other hand, if the sources of the cryptographic tokens are indicated in the data package, the authentication authority can quickly identify the cryptographic tokens in the positioning database (time and place) and the identification data of the signal sources. Once the cryptographic tokens have been identified, the authentication authority can verify the consistency of the data to be protected and the digital authentication code and issue a certificate of data authentication to be protected or declare them invalid.
[0053] As already indicated above, the radio navigation signal receiver preferably comprises at least one security perimeter within which the critical security steps are carried out. These steps include, for example: retrieving the cryptographic tokens from the radio navigation signals, determining the positioning data and generating the digital authentication code. Fingerprint receiver software can be included in the digital authentication code. In this case, the stage of computing the fingerprint software is also carried out within the security perimeter. The person skilled in the art must be aware of which steps are preferably taken within the security perimeter to counter attacks.
[0054] In a variant of the invention, positioning data is calculated not only from pseudorange measurements but also phase measurements.
[0055] Alternatively, the receiver can calculate pseudodistance positioning data and, possibly, phase measurements, of open and encrypted signals. The receiver can be configured to detect inconsistencies between positioning data obtained from an observable open signal and positioning data obtained from an observable encrypted signal. If the calculated geographic positions differ by more than an acceptable limit, the receiver may decide to discard measurements made on open signals and / or even to trigger an alert assuming a counterfeiting attack on open signals if the inconsistency cannot be explained by normal disturbances as multiple routes.
[0056] Advantageously, the receiver will also be able to compute the positioning data based on positioning multi-frequency measurements, that is, using transmission of radio navigation signals at different frequencies. In some circumstances, the receiver may be able to detect detection attacks by radio beacon, that is, signals that are retransmitted by a terrestrial transmitter, with or without the introduction of a time delay. In a beacon detection attack, the data messages from the radio navigation signals remain unchanged. All signals, whether open or encrypted, are exposed to the threat of being detected by radio beacons. A beacon detection attack can be detected when at least one of the available radio navigation frequencies is not detected by beacon radio. The receiver, therefore, can be configured to calculate positioning data for the different frequencies separately, or for different combinations of frequencies and to check for any inconsistency of the different positioning data computed simultaneously (substantially).
[0057] In this context, it is interesting to note that the use of encrypted radio navigation signals does not remove the threat of an interference attack. However, interference can be detected relatively easily by a prior art radio navigation signal receiver.
[0058] Data relating to alerts triggered by the receiver can be advantageously included in the digital authentication code as part of the data to be protected by the receiver. The data could be collected by the authentication authority and used to build a database. The database could be monitored by the authentication authority or another service provider to find detected threats. Interference, forgery, light-beam detection or other detected attacks could thus be notified by the authenticating authority to the competent national authorities to locate and, ideally, neutralize the aggressor.
[0059] Now, moving specifically to the terrestrial segment, an aspect of the invention concerns an authentication authority, as has already been mentioned on several occasions above. The authentication authority performs a method of verifying the authenticity of the data to be protected included in a data package presented to it. Which method comprises receiving a data packet, having been, or appearing to have been, produced according to the method as described above. It is assumed that the data packet submitted to the authenticating authority includes data positioning and a digital authentication code, where the positioning data represents the claimed geographical position and time, and where the authentication code has at least the appearance of being one. (If a data packet submitted to the authenticating authority is clearly in the wrong format, there is no need to continue. The authentication procedure can then be undone and an error message can be issued to the person who submitted the data packet. .) The authentication authority retrieves the one or more cryptographic tokens, which a radio navigation signal receiver would have received had it actually been in the alleged geographical position at the time alleged. The authentication authority verifies that the positioning data and the digital authentication code are consistent with each other. Finally, it authenticates the data packet (including the time and location indication contained in the positioning data) if the positioning data and the digital authentication code are consistent with one another, or rejects the packet data as invalid if the data from positioning and the digital authentication code are not consistent with each other. The certificate, if positive, may contain, if necessary, an indication of the level of confidence that can be attributed to the positioning data, based, for example, on the number of authenticated signals used for the correction.
[0060] It should be noted that the procedure performed by the authenticating authority is adjusted to the format of the data packet, which has to be determined in advance by means of a standard.
[0061] A third-party service provider (for example, a "pay-as-you-drive" insurance company, or a toll authority, etc.) may receive data packages from its subscribers. It can present the data packets to the authentication authority for authentication. The authentication authority then returns a certificate for the applicant to have sent a data packet, indicating whether the data packet, in particular the date and time not contained, is authentic. The third-party service provider could send each data packet it receives from its subscribers to the authentication authority for authentication. Alternatively, it can present samples selected at random from all the data packets it receives. The third-party service provider can also examine the data packets for irregularities and send seemingly irregular data packets preferably to the authenticating authority.
[0062] The authentication authority of preference determines the values of the cryptographic tokens to be distributed through the radio navigation sources. After generation in authentication authority, cryptographic tokens are transmitted, via secure communication, to up-link stations, which send the token to radio navigation signal sources, for example, satellites. Alternatively, cryptographic tokens are generated outside the authentication authority, for example, by one or more command centers of the radio navigation system and transmitted via secure communication to the authentication authority for storage in a file and to the up stations -link for sending to radio navigation signal sources.
[0063] Instead of storing all the cryptographic tokens passed, the authentication authority could use a generating function that produces the cryptographic tokens, corresponding to a certain period of time. In this variant, the authentication authority of preference is prepared to change the generating function, or the parameters, from time to time. The authentication authority must maintain a file of generating functions or parameter settings and their corresponding time periods.
[0064] It should be noted that there may be more than one authentication authority. In the case of a plurality of authentication authorities, there is a preference for a common file of cryptographic tokens or a common computing center for the calculation of cryptographic tokens corresponding to a certain time, which file or computing center of all authentication facilities has. secure access. Alternatively, each authentication authority could have its own computing or filing center. Regardless of which option is chosen, care must be taken to keep cryptographic tokens and / or the function that generates their secret. This can be made easier with a single authentication authority.
[0065] In the signal source segment, an aspect of the invention is radio navigation signal sources, which transmit radio navigation signals, containing one or more cryptographic tokens protected by cryptography, the cryptographic tokens, being updated periodically.
[0066] Another aspect of the invention relates to the radio navigation signals themselves and the use of such signals, for example, to provide an authenticable time and location indication. Radio navigation signals are characterized by one or more cryptographic tokens embedded in their data content and protected by encryption.
[0067] Those skilled in the art will appreciate that the different aspects of the present invention establish an integrated method for providing users of a radio navigation system (end users as service providers to third parties) with a high level of security.
[0068] Encrypted radio navigation usage signals, possibly at multiple frequencies and / or, in combination with open radio navigation signals, from a tamper-proof receiver and the receiver software will give high confidence in the positioning data. In the event of an attack on radio navigation signals (for example by interference, forgery or detection by radio beacon), a receiver that operates in accordance with the above has the best chance of detecting the attack and alerting the user. In addition, a user can easily determine if his receiver is functioning properly by sending a data packet to the authentication authority. When the receiver can be configured to regularly send a data packet to the authentication authority, for example, when it lowers keys to access encrypted radio navigation signals and / or cryptographic tokens.
[0069] The invention allows those who are in possession of a data packet to obtain confirmation that the receiver that the data packet claims has been produced as it was in the stated position at the time stated. If the data packet contains data (for example, a document), the applicant for the data packet to the authenticating authority may also receive confirmation that the new data has been packaged by the receiver at the confirmed location at the time stated.
[0070] The invention thus provides a greater chain of trust, within the scope of a radio navigation system (for example, the future European GNSS or a network of pseudo-satellites) of signals in space for the recipient of a data package containing an indication of time and location. In this sense, the invention achieves end-to-end positioning data authentication, which represents a significant step towards secure radio navigation.
[0071] The invention increases the robustness of radio navigation against malevolent threats in radio navigation signals and ensures data protection against malicious attempts to alter them in positioning and provides a means for location marking and time stamp of any type of documents in a safe way.
[0072] The invention can be usefully combined with an application, increasing the positioning accuracy through the safe delivery of the correction data, allowing more accurate and secure means of positioning and timing. Brief Description of Drawings
[0073] A preferred embodiment of the invention will now be described, by way of example, with reference to accompanying drawings in which: Figure 1 is a schematic illustration of a GNSS configured in accordance with the present invention; Figure 2 is a schematic block diagram of the receiving software; Figure 3 is an illustration of an authenticable data packet; Figure 4 is an illustration of computing an encryption key based on cryptographic tokens retrieved by a GNSS receiver. Description of Preferred Modalities Introduction
[0074] A possible implementation of the invention, then using the European GNSS Commercial Service (CS) (known as Galileo) will be covered in more detail. The commercial service example was chosen here mainly because it will be the first GNSS service to offer encrypted radio navigation signals to civilian users, which is probably the most practical and secure way to achieve independent SIS authentication.
[0075] The example discussed below explains the different aspects of the invention in more detail. The example relates to the production by a radio-navigation signal receiver of digital compilations with the entry of cryptographic token (s) embedded in the CS navigation signals data message for the purpose of authentication: positioning data, produced by an authorized radio navigation receiver based on radio navigation signals, transmitted by a local, regional or global navigation satellite system or a terrestrial pseudo-satellite system; and the identity of the radio navigation receiver and, eventually, the identity of the user and / or receiver of any type of administrative authorization, attributed to the same; and / or where appropriate, documents of any kind, which are the location mark and the time stamp by the recipient. System Architecture
[0076] The architecture of the example is illustrated in Figure 1. The GNSS comprises a ground segment 10, which is responsible for, among others, synchronizing all pseudo-satellites and / or satellites 12 (not shown) and preparing the data message to be transmitted to radio navigation signals. The ground segment 10 includes several up-link stations 14 controlled by a trusted authentication authority, hereinafter referred to as the Authentication Service Center 16.
[0077] The GNSS also comprises a space segment 18 with a plurality of radio-navigation satellites 12 orbiting an average Earth orbit on three or six different orbital planes and / or a plurality (more than 5) of synchronized pseudo-satellites.
[0078] The GNSS user segment 20 comprises users' radio navigation receivers 22.
[0079] Users can be subscribers to a third-party service provider 24, providing geo-located services.
[0080] There is a telecommunication segment 26 for the transmission of data packets from subscriber receivers 22 to third party service providers 24 (the data packet network) and a secure telecommunication segment 28 for the distribution of the navigation keys ("keys navigation ") from the Authentication Service Center 16 to user receivers (from the network of navigation keys). The Authentication Service Center 16 guarantees: the provision of cryptographic tokens; making secret identification numbers available to recipients 22; the authentication of the data packets produced by the receivers 22;
[0081] The solo segment 10 allocates some space in the data messages of the CS radio navigation signals for the transmission of cryptographic tokens. It encrypts the entire data messages before sending them to satellites 12 or ensures that satellites 12 encrypt radio navigation signals.
[0082] The Authentication Service Center 16 produces cryptographic tokens using a state of the art algorithm. The update rate of cryptographic keys that results from tokens is dependent on the level of robustness sought. This fee will be constrained by the level of availability of up-link stations 14 and their connectivity to satellites 12: data messages are actually loaded - and thus updated - via up-link stations for satellites at different points in time. .
[0083] The Authentication Service Center 16 maintains an archive of all cryptographic tokens it has produced.
[0084] The Authentication Service Center 16 has a secure communication link 30 with the ground mission segment of the Galileo system, which controls the up-link stations, for the transmission of tokens, from the Authentication Service Center to the ground segment; and for the transmission of tokens read by the sensor or monitoring stations of the ground mission segment to the Authentication Service Center.
[0085] User receivers 22 are equipped with specific hardware (encryption module) and specific software to retrieve cryptographic tokens from CS radio navigation signals, to generate a digital authentication code using a cryptographic function, having as inputs, at least the positioning data computed by the receiver and the cryptographic tokens and providing a data package, including at least the positioning data and the digital authentication code.
[0086] Third-party service providers 24 can request authentication of their subscribers' data packets to the Authentication Service Center 16. The Authentication Service Center 16 then checks for positioning data (and possibly even more data to protect ) are consistent with the digital authentication code contained in the data package and returns to the third party service provider, a certificate that indicates the result of the verification. Distribution of cryptographic tokens
[0087] The data message for each of the radio-navigation signals produced by the space segment allocates a fixed number of bits for the cryptographic token. This length is determined by the level of robustness foreseen for the application. This length must not be changed; otherwise, the software of all dedicated receivers must be updated to take account of this change in the structure of the data message.
[0088] The values of cryptographic tokens are changed at certain intervals in order to defeat a hacker willing to break the encryption used to produce a digital authentication code. The update rate will be limited by the physical capacity of the land and space segments.
[0089] The data message contains all the data necessary to allow the receiver to make a fixed position with the encrypted radio navigation signals carrying the cryptographic tokens.
[0090] The European GNSS Commercial Service uses encrypted radio navigation signals in the E6B frequency band. The data message of E6B signals can be used to transmit cryptographic tokens. In the following description, it thus assumes that cryptographic tokens are transmitted in the E6B data message.
[0091] According to Mission Requirement Document v7.0, the European GNSS that varying the encryption code on the E6B (data channel) and E6C (pilot signal without data channel) signals is based on a symmetric Cryptography algorithm Advanced Strong Standard (AES) with 256-bit keys. The algorithm is used in counter mode. The secret keys required by GNSS receivers to access encrypted radio navigation signals, that is, the navigation keys, are managed and distributed by the Authentication Service Center to users and are renewed between each week every 3 months. For the purposes of their distribution, the navigation keys are encrypted with the receiver's secret ID and sent to the receiver via the Internet. If the receiver has no direct interface to the Internet, the navigation keys will be sent in a first step to a personal computer and loaded in a second step in the receiver, for example, with a USB flash drive. Thus, the length of the receiver's secret ID is assumed here for a quantity of 256 bits.
[0092] As indicated in surveys, a radio navigation signal is qualified as safe if one of the following conditions is met: the radio navigation signal is encrypted (that is, the signal range code is encrypted) with a state of the art encryption algorithm, or the radio navigation signal is not encrypted, but the data message (including data cryptographic tokens), which it transmits is encrypted with a state of the art encryption algorithm; or the radio-navigation signal and its data message are encrypted with the same state-of-the-art encryption algorithm or two different encryption algorithms, with two different sets of keys.
[0093] The E6 signals thus allow to carry out totally reliable pseudo-distance measurements (in contrast to E1 signals, which can be easily falsified) and, thus, to compute the PVT equally totally reliable.
[0094] The Galileo Commercial Service Authentication Service Center computes a cryptographic token for each satellite and for each period of validity of cryptographic tokens. These cryptographic tokens are sent to satellites via an up-link station and then transmitted by satellites.
[0095] Each SVi satellite (i being the number of satellites or "space vehicle") transmits a specific cryptographic token, called "NONCESVi", below the data message. The length of each NONCESVi could be, for example, 32 bits.
[0096] The data message comprises, among others, within 448 bits: the navigation message for E6B. This will allow receivers to continue navigation even in an environment where E1A and E5A signals are interfered with or falsified. This will interfere with a maximum of 50 bits per second of the 448 bits per second data bandwidth in E6B.
[0097] Additional data, allowing the receiver to reconstruct the navigation message to E1A, allowing navigation E6B and E1A, even in cases where E1A is falsified. An unpredictable value for each new encryption token (NONCESVi).
[0098] NONCESVi is specific for SVi satellite. Thus, normally: NONCESVi (t) ≠ NONCESVj (t), if i ≠ j. However, there may be times when two or more cryptographic tokens are accidentally the same.
[0099] The Authentication Service Center archives all encryption moments in one file (the NONCE file). Computation of data packets by the receiver
[0100] Figure 2 provides an overview of a possible implementation of the receiving software. The software comprises four main components: the SiS authentication software; the key management software; the encryption / decryption software; the navigation software.
[0101] The keys required for user receivers to adhere to the radio navigation signal and / or cryptographic tokens are transmitted via a secure communication network and managed within the receiver in an encryption module and the key management software.
[0102] The receiver's software depends mainly on the pseudo-distance measurements calculated on the basis of safe radio navigation signals. Only positioning data obtained from safe radio navigation signals can be considered safe.
[0103] In addition to the usual inputs provided by the navigation message for each radio navigation signal, additional data can be added to the data message of the safe radio navigation signals in order to assist the navigation software. For example, the receiver's navigation software may take into account: integrity data, released by the GNSS operator on secure radio navigation signals; navigation correction data provided by the GNSS operator or the Authentication Service Center; clock differentials with other spatial segment frequency (s).
[0104] The navigation software can be configured for Autonomous Receiver Integrity Monitoring (RAIM) and / or comprises an augmentation function (powered by correction data), for example, Precise Point Positioning.
[0105] The receiver produces a data packet, comprising two parts: Part 1 comprises readable information, containing "text" data, including positioning data. Part 2 is the so-called digital authentication code.
[0106] The digital authentication code allows the Authentication Service Center to authenticate the data to be protected. The digital authentication code can cover part or all of the data to be protected. If the digital authentication code contains a hash value of certain data, this data must be present in the plain text part (part 1). Otherwise, the authentication service center will not be able to verify the digital authentication code.
[0107] It is possible to include data in part 1 and part 2 of the data package. While it is true that this duplicates information in general, it may be interesting for some applications to be able to retrieve the data contained in the digital authentication code, in situations where the latter disagrees with part 1.
[0108] Returning now to the preferred radio navigation receiver illustrated in figure 3, it is at least one counterfeit-proof biofuel GNSS receiver (E1AE6B bands). Preferably, the receiver is configured to handle radio navigation signals E1, E5 and E6. The receiver's security perimeter includes at least E6 correlators and baseband processing.
[0109] The receiver is also equipped with an inertial navigation system (INS). The receiver is equipped with a USB slot. The user inserts a dedicated USB flash memory drive into the slot to send the navigation keys. The USB flash memory drive can also be used to transfer other data to the receiver, such as the Public User ID, which could be a driver's license, for example.
[0110] The USB flash memory drive also stores all data packets, or at least or samples of them, at predetermined intervals, for a predetermined period. All data packets are stored in an encrypted format to protect privacy, for example if the USB flash drive is stolen. The data packets can be transferred from the USB flash memory drive to the authentication service center via the personal user's computer, each time the user requests on the Authentication Service Center website via the nearby navigation keys. The transfer of data packets allows the Authentication Service Center to perform remote PVT authentication a posteriori. For this application (ie deferred remote PVT authentication), the Authentication Service Center sends - with the user's authorization - all data packages and their respective certificates to the user's service providers.
[0111] The receiver can be equipped with a wireless telecommunications terminal, such as GPRS, G3 or G4. This telecommunication link is used to achieve near real time PVT authentication for third parties. This function (ie, real-time remote PVT authentication next close), would be very valuable for real-time tracking of sensitive goods or programs, but less interesting for applications such as load user loading or insurance schemes "pay-as-you-drive".
[0112] The Public Receiver ID is preferably marked on the receiver in a visible way.
[0113] The Private Receiver ID is stored in a tamper-proof memory. This is not known by the user, nor by any other party, except for the Authentication Service Center.
[0114] The receiving software is stored in the same or other tamper-proof memory. Preferably, the memories for the receiver software and the Private Receiver ID, respectively, are separated, in order to avoid potential deletion of the Private Receiver ID during a software update.
[0115] The receiver is preferably powered by a safe power cable so that it cannot be physically disconnected.
[0116] The receiver can also be equipped with a DSCR transmitter transmission within a short distance of the information of whether the receiver is turned on and is functioning properly. These measures may prevent a user from voluntarily turning off their receiver to avoid payments or penalties due to a service provider.
[0117] The receiver software has four main functional blocks: the navigation software responsible for computing the PVTs of the navigation signals; the key management software responsible for sending the encrypted navigation keys to the user's USB flash memory drive; the SIS authentication software responsible for detecting blocking attacks and detection by radio beacons; the encryption / decryption software, responsible for producing the digital authentication code and decrypting the encrypted navigation keys.
[0118] The receiver allocates two correlation channels for each satellite (one in E1A and one in E6B). The receiver then acquires the variation codes in E1A and E6B, reads the navigation message in E1 and E6B, and extracts the nonce transmitted by the satellite from E6B data.
[0119] The navigation software calculates two PVT solutions, the first based on E6B signals only and the other based on all available signals, including E1 and E6.
[0120] The first PVT is called PVTE6. This is calculated using only E6B pseudo-distance measurements (PRE6).
[0121] The second PVT is called PVTE1, E6. It is based on ion-free pseudo-distance measurements (referred to as ion-free PR), which are calculated according to
[0122] The navigation software can estimate a four-dimensional trust box centered on PVTE6 and defined by time, horizontal and vertical dimensions. This takes into account all possible errors in navigation based only on E6B. The four dimensions of the trusted PVT box can be calculated by the receiver based on the data provided by the Authentication Service Center on the state of the constellation.
[0123] The size of the reliable PVT box can be significantly reduced, if the software is associated with a high-precision service on E6B allowing the receiver to benefit from greater accuracy of satellite positions (high-precision ephemeris) and clock deviations of satellite.
[0124] It is interesting to note that PVTE1, E6 is more accurate, but not entirely safe in relation to PVTE6 than PVTE6 is less accurate, but totally reliable. The PVTE6 position is the only reliable solution, as it is calculated based on safe and reliable signals (because they are encrypted). This position time is accurate within the error ranges determined in all four dimensions Dx, Dy, Dz and DT.
[0125] The trust box indicates that the receiver's true position and time (exact PVT) are contained in the trust box, with a predefined probability (confidence level).
[0126] The dimensions of the trust box depend on the configuration of the Galileo constellation at the point in time in question. The dimensions of the box could be significantly reduced if the system were coupled with a high-precision application applied over E6B.
[0127] E1 signals are falsified, the receiver will be able to calculate PVTE6, E1 and thus trigger a forgery alert, or will be able to calculate PVTE6, E1 which is likely to fall outside the reliable PVT box. If PVTE6, E1 is certainly outside the limits of the reliable PVT box, the receiver will also trigger an alert.
[0128] In the event of such an alert, the receiver will produce only PVTE6 and the size of the trust box. The latter will then be considered the best approximation of the true position and time.
[0129] If no alerts are triggered, the receiver will produce PVTE6 and PVTE6, E1. PVTE6, E1 will then be considered the best approximation of the true position and time. Navigation key management
[0130] The user can download the E6B signal navigation keys over the Internet on a regular basis, for example, once a month. These keys will be produced by the Galileo operator or, alternatively, by the authentication service center.
[0131] The Galileo operator assigns E6B loads on all satellites with the same navigation key to encrypt the navigation signals with this single navigation key. The authentication solution described here could also work with a different navigation key assigned to each satellite.
[0132] The user downloads the navigation keys in advance of the change. The user will log into the secure Internet site of the Authentication Service Center. For this purpose, the user will be identified by his login (for example the Public Receiver ID) and a secret password. When identified, you can submit a request to renew the key and insert the USB flash memory drive into the computer for this purpose.
[0133] The request is handled by the Authentication Service Center database software. The database contains all logins, secret passwords, Public Receiver IDs and Private Receiver IDs. The database server identifies the Public Receiver ID and thus retrieves the corresponding Private Receiver ID. The Private Receiver ID is used to encrypt the navigation key with a symmetric encryption algorithm. The website then downloads the encrypted navigation key on the USB flash drive to the user's personal computer.
[0134] However, the website application will load all data packets stored on the USB flash drive inserted in the personal computer. These data packets are later certified by the authentication service center and then sent to the user's designated third-party service providers.
[0135] When the new navigation keys have been downloaded to the USB flash drive, the user inserts the USB flash drive for the radio navigation signal receiver. This insertion triggers the following actions. The receiver's key management software checks whether a new encrypted navigation key is stored on the USB flash drive. In this case, the software loads the encrypted navigation key into a memory within the security perimeter of the receiver.
[0136] The encryption and decryption software then decrypts the encrypted navigation key with the help of the Private Receiver ID stored within the security perimeter and saves the decrypted version of the navigation key in another tamper-resistant memory within the security perimeter, along with the parameters of effectiveness over time.
[0137] The key management software excludes navigation keys that have expired.
[0138] If necessary, the key management software alerts the user via the receiver interface to the imminent extinction of the validity of the current navigation key and, if necessary, the absence of a valid navigation key for the next navigation period. In the absence of a key for the current period, the receiver will not be able to track and acquire E6B signals. In this case, the SIS standalone authentication function is lost and subsequent remote PVT authentication by the authentication service center is no longer possible. Real-time processing of SIS authentication by the receiver
[0139] In the first instance, the SIS authentication software indicates to the user through the receiver interface that Galileo E6B satellites data messages have been acquired and decrypted, that is, which Galileo satellites are visible from the receiver when the latter calculates the PVT.
[0140] The second task of SIS authentication software is to continuously monitor and detect interference attacks. For example, the SIS authentication software triggers an interference alert if the receiver loses one frequency but still receives signals on another frequency from the same satellites. This alert indicates which frequency has been missed.
[0141] If E6B band signals have been lost, but E1 or E5 signals are still read by the receiver, the SIS authentication software triggers an alert indicating that satellite navigation is no longer secure and asks the navigation software to switch to mode INS navigation
[0142] If the radio navigation signals are lost at all frequencies, the SIS authentication software triggers an alert indicating that satellite navigation is no longer possible and asks the navigation software to switch to INS navigation, too.
[0143] The SIS authentication software detects attacks, that is, situations where an attacker modifies the counterfeit navigation data transmitted in open signals. A counterfeit alert will be triggered, for example, when the ephemeris to read on the E1 signal (not immune to counterfeiting) are different from the ephemeris to read on the E6 (immune to counterfeiting according to the current state of the art).
[0144] SIS authentication software can also detect beacon detection attacks in some situations. A radio beacon detection attack is considered to take place where signals in space are re-broadcasted by a terrestrial transmitter, with or without the introduction of a time delay. In a radio beacon detection attack, signal data messages in space remain unchanged. All signals, be they open or encrypted as E6B can be detected by radio beacon. A beacon detection attack can be detected when at least one of the available radio navigation frequencies is not detected by beacon radio, for example when PVTE1 or PVTE5 leaves the PVT box entrusted, centered on PVTE6 · The software here detects that an inconsistency of the positions computed each as a function of the signals at a frequency each time.
[0145] However, the SIS authentication software cannot detect a beacon detection attack, modifying, in parallel, the signal transmission delay on all radio navigation frequencies. That said, the introduction into the receiver of an inertial navigation system (INS) should in theory allow the receiver to detect such attacks. When subjected to such attacks, the receiver equipped with some INS must detect an inconsistency between a new PVT calculated based on the INS and the last PVT and the PVT calculated based on the navigation signals.
[0146] The SIS authentication software would be on request to check the software embedded in the receiver with the help of fingerprints stored on the USB flash drive. If the software's SHA256 is not compatible with the fingerprint in question, it means that the software installed on-board the receiver has been modified and an alert about the integrity of the software will be triggered. PVT encapsulation by the receiver
[0147] In addition to a position shown on the map on the screen, the receiver produces within its security perimeter it is intended to be sent to an outlet (the data packet) and used by third parties. The data package consists of two parts (cf. Fig. 3): Part 1 (“the readable information”), which includes the following information: PVTE1, e6; Receiving Public ID; Public user ID (optional); Part 2 ("the digital authentication code”) is an encryption of the following information: A 27-bit field identifying Galileo's satellites, used for calculating PVT PVTe6; PVTE6; The dimensions of the entrusted PVT box; PVTE1, e6; Public user ID (optional); the fingerprint of the receiver software computed with SHA256.
[0148] The data package must not be divided, truncated or modified in any case. Otherwise, it would lose its authenticable character. It must therefore be produced, transmitted, stored and archived forever in the same format.
[0149] The encapsulation software can produce Part 21 (“the readable information”) clear or encrypted, depending on whether the user wants to protect their privacy. The encryption of Part 21 is then done only for the purpose of protecting privacy, but not for authentication purposes, later on, the data packet. The possibility of encrypting Part 21 is a complement to the authentication request, but not one of its essential characteristics.
[0150] Part 1 ("the readable information") can be encrypted or unencrypted, depending on the choice made by the receiver's user to protect their privacy, since Part 21 can be taken advantage of by the malicious parties at any time after this information has left the receiver. If Part 21 is encrypted, the following scheme will be applied to manage the user tribe:
[0151] The user enters a secret key for the receiver.
[0152] Part 1 is then encrypted with this secret key using a symmetric encryption algorithm.
[0153] The user has the responsibility to distribute his secret key to his tribe and service providers in a secure manner.
[0154] Part 2 (“the digital authentication code”) is necessarily encrypted and cannot be read, except by the authentication service center. The encryption algorithm is at least a 192-bit elliptic curve (ECIES) integrated cryptography scheme. The software producing Part 22 is called after that, the encryption / decryption software.
[0155] The receiver secret ID is unique, unknown to the user and third parties and protected within the security perimeter of the receiver.
[0156] Part 1 ("the readable information") is intended for use by third parties, including geo-located or calendar service providers, whereas Part 22 which will accompany Part 21 in any circumstance, can be read and therefore used only by the authentication service center.
[0157] In addition, users can transmit the same data packets (Partel + Part 2) to an unlimited number of geo-located providers or timing services and their tribes (relatives, friends, colleagues). Each recipient of this information can actually submit an authentication request at any time before the authentication service center, provided that Part 22 has remained linked to Part 21.
[0158] The main task of the encapsulation software is to encrypt the information essential for future PVT authentication, encapsulating it in Part 22 of the data package in a two-step process, as described below.
[0159] All encryption operations are performed within the security perimeter of the receiver.
[0160] Part 2 (“the digital authentication code”) is produced by two successive encapsulations. The first encapsulation covers a data set consisting of: PVTE6, The four dimensions of the entrusted PVT box, PVTE1, E6, Receiving Public ID, Public user ID (optional), the fingerprint of the receiver software computed with SHA256.
[0161] This data packet is encrypted using a symmetric encryption algorithm with a corresponding key for concatenation in a predetermined order of all times to be read by the receiver on the E6B data messages. This encryption produces the first encapsulation later called En1.
[0162] Encryption is achieved by concatenating 8 satellite cryptographic tokens to visibility in a predetermined order, for example the increasing classification of satellite identifiers. If there are fewer than 8 Galileo satellites in visibility to the receiver, the moment field left vacant will be replaced by an extract from the Receiving Private ID. This precaution is taken to guarantee maximum robustness to all packages with a key of the maximum length (256 bits). Fig. 5 illustrates the calculation of an encryption key (with a length of 256 bits) when only five satellites are in view of the receiver. The cryptographic key is obtained by concatenating the available cryptographic tokens (NONCESvi1,. ··, NONCEsví5) and a Part 2 of the receiver's private ID. The ID of the private receiver is truncated in order to obtain a key with the predefined length.
[0163] The second package comprises a data package consisting of: En1; a 27-bit element revealing the Galileo satellites used to calculate the PVT and thus to encrypt En1 (through the concatenation of the corresponding NONCEs);
[0164] In a second phase, this packet is encrypted using a symmetric encryption algorithm with the Secret ID receiver as the key. This encryption produces the second encapsulation later called En2. En2 is Part 22 of the data package (“the digital authentication code”).
[0165] Part 1 (“the readable information”) and Part 22 (the digital authentication code) are then finally assembled in a predetermined format for the data packet. The data packet is sent over any telecommunications network, later called the data packet network - to all service providers, with which the user has signed a contract or agreement. Data packet distribution
[0166] Data packets can be transported by any type of media. The data in the network package could be a terrestrial radio frequency network used for data transmission such as GPRS, G3 or G4, which proves to be convenient for reaching mobile vehicles. They can be transmitted in real time or almost in real time to a third party service provider. The data packets could also be transmitted at a delayed time, preferably at regular intervals. This could be done with a USB flash drive and on the Internet, or through any other telecommunications connection. The provider can request authentication from the authentication service center of the data packets it receives (in real time or in deferred time).
[0167] The network of navigation keys and the data packet network can be from the same network. This situation will be easier to handle at the receiver, as it reduces the number of telecommunications terminals.
[0168] This situation can also present another advantage for applications that do not require remote real-time or near real-time PVT authentication. Instead of transmitting packages to a number of third parties (service providers) interested in the data produced by the recipient, the recipient can send all of his packages to a focal point, the authentication service center, which can send them to the third parties assigned together with a certificate. The sending of one or more data packets to the authentication authority can be made conditional for the delivery of the nearby navigation keys. The user will therefore be forced to provide, at certain intervals, their positioning data, as otherwise they would lose access to the and / or secure radio navigation signals and the cryptographic tokens. Another advantage of this approach is that the authentication service center can verify the integrity of the receiving software (using the fingerprint software contained in the digital authentication code) and that one can thus avoid distributing the navigation keys to receivers with a perimeter cracked security guard. Protection of PVT after its computation
[0169] The receiver produces the data packet, which consists of two parts: Part 1 is “the legible information”, containing the PVT in plain text, provided in a predetermined format and the recipient's identifier ("the public Receiver Public ID"). Part 2, the digital authentication code that includes, among others, in an encrypted format, the Jdentification of the receiver, PVTE6 and PVTe6, ei and the dimensions of the entrusted PVT box.
[0170] A terrestrial telecommunications segment (later called the data packet network) ensures that the information produced as described above is transmitted to any location-based service provider. Information can be carried by any type of media: (almost) in real time through a ground-based wireless network such as GPRS, G3 or G4; or in deferred time, preferably at regular intervals, via USB flash drives and the Internet.
[0171] The recipients of the data packages may be third-party service providers who can submit an authentication request to the authentication service center. Alternatively, data packets can be sent to the authentication service center. In this case, third-party service providers will connect to the server's authentication service center to obtain this center from their clients' data packages and their respective certificates.
[0172] The authentication service center is the only entity capable of reading the digital authentication code (part 2). At the request of a service provider, wanting to check the data packets sent by its customers, the authentication service center checks whether the "text" data (part 1) and the digital authentication code are consistent with each other. The positioning data will be considered correct, only if the authentication service center can guarantee that the positioning data in question was produced by a reliable and identifiable receiver and calculated by the licensed and recognized software, based on radio navigation signals. safe. If they match Part 21 and Part 22 of the data package, the authentication service center provides the service provider with a certificate, which guarantees that the data to protect has been integrated into the data package at the time indicated in the indicated location. If the two parties do not match, the authentication service center provides the applicant with a certificate warning that the data package has failed the authentication test (for example, because the positioning data or the receiver's identification has been corrupted, and that therefore, the data packet cannot be authenticated).
[0173] A third-party service provider can send an authentication request to the authentication service center along with the complete data package received by the service provider from one of its customers. The authentication authority can be configured to interpret the presentation of a data packet as an authentication request.
[0174] The authentication service center then decrypts Part 22 (“the authentication key”) and verifies that the information contained in Part 22 is consistent with the information contained in plain text in Part 21.
[0175] If they match the data of the two parties, the authentication service center provides the requester with a certificate, which certifies that the data package passed the consistency check and that, therefore, it can be trusted.
[0176] If the two parties do not match, the authentication service center provides the requester with a warning that the data package has failed the consistency check and that, consequently, it cannot be authenticated from the certificate. Remote PVT authentication processing
[0177] If a service provider or any third party is willing to verify the veracity of the information contained in Part 1 (“the readable information”) of a data package, it has to deal with the authentication service center.
[0178] In this embodiment of the invention, only one authority in the world is able to authenticate the data packets produced by the receivers. By authentication it is intended to send to any applicant a certificate indicating whether the PVT, the Receiving Public ID and, if applicable, the public user ID, as stated in 1 part in clear text is correct and at what level confidence can be given to this information. The authority in question is the authentication service center.
[0179] The authentication service center handles all requests for authentication certificates you can receive using specific software, hereinafter called the authentication software. Requests to submit candidates for authentication certificates in conjunction with the corresponding data packets over a secure network, called the certificate network (reference number 32 in Fig. 1). The certificate network could be achieved through encrypted data exchange over the Internet.
[0180] The authentication software reads the Receiving Audience ID in Part 1. This software has access to three authentication service center databases: the files of all cryptographic tokens; the list of all pairs a Receiver Public ID and a Receiver Secret ID.
[0181] A collection of the footprints of all versions of licensed receiver program codes.
[0182] The authentication service center manages and updates the second database, where it records all pairs of Public ID Receivers and secret receivers for the entire fleet of licensed receivers. The authentication service center would be assigned couples of Public ID Receiver ID and Secret Receiver to manufacturers licensed to produce receivers. Step 1: Selection of Part 1
[0183] In the first instance, the authentication software verifies that Part 1 contains a PVT and Receiver Public ID correctly. For example, if Part 1 was encrypted before being sent as an attachment to an authentication request by either party, the authentication request will abort. In particular, Part 1 must be clear ie not encrypted.
[0184] If the declared PVT and / or Receiving Public ID is not (are) correctly, the authentication software issues a certificate indicating that the authentication process cannot be performed due to corrupt Part 1. Step 2: First decryption of Part 2
[0185] The authentication software retrieves the receiver's secret ID, based on the Receiving Public ID declared in Part 1 (“the readable information”), the receiver, which produced the data packet in question.
[0186] The authentication software then uses the secret recipient's ID to decrypt Part 2 - or En2 - the data packet. It will then read En1 - not yet usable since En1 is encrypted - and a 28-bit pattern identifying the Galileo satellites used for calculating the PVT.
[0187] If the authentication software cannot decrypt Part 2 with the identification of the secret recipient, then the authentication software will issue the certificate with an alert indicating that it wants to: the Receiving Public ID has been corrupted, meaning that the corresponding secret recipient ID is not the correct decryption key; or Part 2 (“the digital authentication code”) has been corrupted and therefore cannot be decrypted.
[0188] A certificate with such an alert will imply that the PVT declared in Part 1 cannot be authenticated. On the other hand, this does not necessarily mean that the PVT has been defrauded or falsified.
[0189] If the authentication software can decrypt Part 2 with the recipient's secret identification, then the authentication software will issue preliminary information on the certificate indicating that the Receiving Public ID declared in Part 1 is correct. Step 3: Second decryption of Part 2
[0190] Based on the list of Galileo satellites, declared in the En2 space vehicle identifier field, the authentication software calculates the decryption key for En1, thanks to the files of the cryptographic tokens of all Galileo satellites. This key is a concatenation in a predetermined order of the cryptographic tokens retrieved based on the calendar provided by Part 1 of the data packet (and possibly the ID of the private recipient).
[0191] Thanks to this key, the authentication software is able to decrypt En1 and, therefore, to access all the following data, calculated by the receiver: PVTE6, PVTe1, E6. Receiving Public ID, Public user ID (optional), the dimensions of the entrusted PVT box.
[0192] The authentication software reads all of the data - contained in Part 2 in an encrypted format - and compares it with the data in Part 1 to verify that the two sets of data are consistent.
[0193] For this purpose, the authentication software will check: if PVTE1, e6 corresponds to PVT declared in Part 1; if PVTe1, e6 is contained in the entrusted PVT box, centered on PVTe6 · if the public user ID optionally declared in Part 1 games with the public user ID contained in Part 2.
[0194] whether the hash value (fingerprint) of the software contained in Part 2 corresponds to a version of the software recognized by the authentication service center as trusted.
[0195] Depending on the result of these checks, the software produces a digital certificate that indicates whether the declared PVT is correct and if so, what is the reliable precision attached to it and whether the declared public user ID, if any, is correct.
[0196] The reason for a two-step encryption and then two-phase decryption is linked to the fact that the authentication software cannot guess in advance which satellites were in the receiver's visibility at the time of the PVT calculation. In theory, one encryption and one decryption could have been sufficient. In fact, based on the PVT calendar declared in Part 1 and its position on the globe, the software could derive that Galileo's satellites of 8 or less were then in the sky above the receiver. However, some of these satellites could have been masked and consequently not detected by the receiver. In order to obtain the right decryption key, the software would have to perform tests of 28 with all possible concatenations of cryptographic tokens, corresponding to the combination of situations where each of the 8 satellites has been seen or not. To avoid these tests, which could delay authentication processing, second encryption and first correspondent decryption will give the authentication software the correct information about which satellites have to be taken into account to calculate the decryption key to gain access encapsulated PVT. Step 4: Transmission to the requester of an authentication certificate
[0197] The authentication service center sends the data packet sent to the requester together with a certificate stating: Info 1: if Part 1 is in the correct format; Info 2: if so, if the declared Receiving Public ID is correct; Info 3: if so, if the declared PVT has not been tampered with; Information 4: if so, if the on-board software the authentication receiver is recognized by the authentication service center. Information 5: if so, if the navigation messages on E1, E6B (and optionally also E5A) are consistent; Information 6: in this case, if the declared PVT is contained in the box of the trusted PVT; Info 7: if the declared public user ID is correct; Information 8: in this case, the authentication accuracy measured in meters and based on the dimensions of the reliable PVT box. Infos 1 to 8 are Boolean data. Information 8 is an integer. These pieces of information indicate the following: If info 1 is FALSE, then the certificate has no value of any kind and the other Infos are irrelevant. If info 2 is FALSE, then the certificate has no value of any kind and the other Infos are also irrelevant. If Info 3 is FALSE, then the certificate that proves that the PVT declared in Part 1 has been modified after being computed at the receiver; If Info 4 is FALSE, then the certificate that proves that the software used to calculate the PVT is not known to the authentication service center; If Info 5 is FALSE, then the certificate proves that the receiver was supposedly subjected to an E1 spoofing attack, but that PVTE6 is still reliable; If Info 6 is FALSE, then the certificate proves that the receiver has probably been subjected to an attack on radio navigation signals, but that PVTE6 is still reliable; If Info 7 is FALSE, then the certificate that proves that the public user ID, if any, declared in Part 1 has not been modified but that after its computation at the receiver.
[0198] The certificate does not offer the PVT or Receiving Public ID. In other words, if Part 1 (“the readable information”) is sent in an encrypted form or if it is missing, then the applicant is considered by the authentication service center not to be allowed by the recipient user to gain access to this information. Then, the authentication service center will reveal itself to be the PVT or Public Receiver ID. In other words, the authentication service is not intended - although it could technically be done Part 2 (the digital authentication code) has not been encrypted - to break the privacy protection.
[0199] The presentation of certificates for data packets coming from all parts of the world indirectly allows the authentication service center to guarantee worldwide surveillance of the navigation frequencies and, therefore, to detect and locate the group, forging and tracing for attacks by beacon radio. The authentication service center, for example, could alert the national authorities of the states involved in such identified attacks. Robustness against GNSS threats Robustness against interference
[0200] The application cannot protect against a simultaneous attack on all browsing frequencies. However, if at least one of the navigation frequencies is not attached - the group's attack will be detected and defeated, that is, the receiver can still count on the PVT derived from the frequency in question. Robustness against counterfeiting
[0201] Existing counterfeiters cannot simulate any coded signal. In particular, they cannot simulate Galileo E6B varying codes. Therefore, E6B codes are not vulnerable to threats of spoofing.
[0202] However, a first direct acquisition over E6B is very complex, due to the fact that the E6B spreading code is no periodic encryption strings. A good time estimate is mandatory and implies that a first signal acquisition is made over E1A. This first time estimate will allow you to start the acquisition process in E6B. If the navigation message in E1A is violated (for forgery) then it is not possible to start the acquisition of E6B. Thus, the first countermeasure is to verify if E6B acquisition can be carried out. Otherwise, the receiver used a compromised E1A signal.
[0203] In addition, to calculate a PVTE6, reliable navigation data (ephemeris, clock corrections, etc.) are required in the E6B data message.
[0204] Therefore, the authentication receiver checks the integrity of each navigation received data by comparing the fingerprint of the navigation data, received the E6B encoded signal and the value of SHA-256, the navigation data, received in E1A (for all Galileo satellites used to calculate PVT solutions).
[0205] The cryptographic token aims to provide an anti-replay mechanism against attack on the encryption of the digital authentication code.
[0206] The authentication receiver will calculate two PVT solutions (using the same Galileo satellites). However, although PVTE1, E6 is the most accurate, only PVTE6 is robust against counterfeit attacks and is the trusted reference to be used to determine the area of trust (standalone SIS authentication). Robustness against radio beacon detection
[0207] Radio beacon screening is the most effective means of deceiving GNSS receivers. Even so-called robust services such as GPS P (Y) -code or Galileo PRS are not immune to detection by beacon radio.
[0208] However, detection by radio beacon can be defeated in the case where it is the attacker who does not meacon the entire spectrum of frequencies used for navigation purposes, that is, E1, E5 and E6. A multi-frequency receiver can then easily detect inconsistencies between the positioning provided by PVTE1, PVTe5 and PVTe6- It will be the case for receivers according to the present example.
[0209] Some beacon detection attacks can also be detected where a receiver detects a sudden jump and / or position at the time of the computed PVT. Authentication receivers will integrate this function.
[0210] Detection attacks by radio beacon exerting a progressive traction of time andor position on receivers can go unnoticed, if these GNSS receivers have only signals. Such attacks can be detected since the receivers are also equipped with inertial navigation sensors. Authentication receivers will include such sensors. Robustness against possible changes in positioning data
[0211] The application cannot prevent an attacker from modifying the PVT and / or the Receiving Public ID in Part 1 of the data package, especially if the information to protect is stored or transmitted in plain text. The application, however, will serve to detect such a change.
[0212] To combat tampering with PVT, the receiver's software may include an algorithm that allows the user to protect the generated data package from being sent to service providers and user tribes. This encryption is a good way to protect against an attempt by a third party to modify the PVT and / or the Receiving Public ID in Part 1 of the data package. Vulnerabilities against attacks from the application itself
[0213] All security assets, including the receiver's firmware, are implemented within the security perimeter of the authentication receiver.
[0214] In addition, the host equipment includes mechanisms for verifying data integrity and software used to calculate PVT.
[0215] Dedicated GNSS receiver will be equipped with an encryption module, preventing critical security and software assets from being read and thus stolen (including by the user or the service provider).
[0216] The threat here is that an attacker produces packages of trusted false data, that they will pass the test certificate successfully and that, however, are forged. In order to defeat the authentication request, the attacker will have: to break a private ID of the receiver; to file during the period of time in question with the attack at all times and on all ephemeris; and to reverse engineer the encapsulation software.
[0217] Action (1) is going to be very difficult to achieve. It will be necessary to obtain unauthorized access to the authentication service center receiver's identification database or to read the tamper-proof memory contents of the authentication receiver. Or alternatively, the private receiver ID can be broken by brute force attacks, but the only data encrypted with the private receiver ID will only be 28 bits long. Current state-of-the-art algorithms are already immune to brute force attacks with the computational power of today's computers. The short length of encrypted data would make it even more difficult for an attacker to break the key in the future. Another threat is that the manufacturer maintains a trace of the relationship between the Receiving Public ID and the private recipient ID and that this tracking is stolen: manufacturers must be compelled to destroy this information after the production of the authentication receivers.
[0218] Action (2) is only possible if the attacker has access to the navigation keys for a long period of time and can archive all moments to be identified in the E6B data message. Action (2) should be avoided through: imposition of a security perimeter on all CS receivers (the first step is not to make the commercial service interface control document public and to allow the construction of commercial service receivers only for licensed manufacturers); define high standards of security perimeter for authentication receivers; protect the distribution of the navigation keys.
[0219] Action (3) can be achieved by first stealing licensed encapsulation software. The distribution and updating of this software must be ensured through protected channels. Reverse engineering will occur satisfactorily by regular and frequent refreshment of cryptographic tokens.
[0220] None of these actions are attainable by any hacker based on the best current technologies.

权利要求:
Claims (15)
[0001]
Method to provide an indication of time and authenticable location using a radio navigation signal receiver, said method being characterized by the fact that it comprises the following steps: a) receive the radio-navigation signals transmitted from a plurality of radio-navigation signal sources, at least some of the radio-navigation signals containing one or more cryptographic tokens protected by cryptography, said cryptographic tokens being updated periodically ; b) recover said cryptographic tokens from radio navigation signals that contain them, by decryption; c) determining the positioning data based on received radio navigation signals, said positioning data including the geographical position and the time of the radio navigation signal receiver; d) generate a digital authentication code using a cryptographic function having as inputs at least the said positioning data and recovered cryptographic tokens; and e) producing a data package including a first and a second part, said first part containing the positioning data and a public identifier of the receiver, and said second part containing said digital authentication code.
[0002]
Method according to claim 1, characterized by the fact that each of the said radio-navigation signals contains a specific cryptographic token for the source of the radio-navigation signal that transmits said radio-navigation signal.
[0003]
Method, according to claim 2, characterized by the fact that said first part or second part also contains source identification data that identify the sources of the radio-navigation signal having transmitted the radio-navigation signals from where said cryptographic tokens have been recovered.
[0004]
Method according to any one of claims 1 to 3, characterized by the fact that said cryptographic function produces, as a digital authentication code, a hash value or a cipher text with at least the positioning data, based on a key that is a function of at least one of the recovered cryptographic tokens.
[0005]
Method, according to claim 4, characterized by the fact that said cryptographic function produces the hash value or ciphertext with at least the positioning data and the said public identifier of the receiver.
[0006]
Method according to claim 4 or 5, characterized by the fact that it comprises providing more data to protect, such as, for example, user identification data, signal integrity data in space, control of the receiving software, more positioning data , digital signature identifying the user and / or one or more digital documents, in which the aforementioned digital authentication code is generated using the said cryptographic function, with complementary data to protect as input.
[0007]
Method according to claim 6, characterized by the fact that said cryptographic function produces a hash value or a ciphertext of at least more data to protect, based on said cryptographic key.
[0008]
Method according to any one of claims 2 to 7, characterized by the fact that said cryptographic key comprises a concatenation of said cryptographic tokens.
[0009]
Method according to claim 8, characterized by the fact that said receiver has stored in it a secret receiver identifier known to the authentication authority, and in which said cryptographic key comprises a concatenation of the cryptographic tokens and a part or all of the secret receiver identifier.
[0010]
Method according to any one of claims 1 to 8, characterized by the fact that it comprises encrypting said second part, for example, according to a symmetric encryption scheme.
[0011]
Method according to any one of claims 1 to 10, characterized in that the radio navigation signals that contain a cryptographic token are encrypted radio navigation signals and / or contain said cryptographic token as part of a content of encrypted data.
[0012]
Method according to any one of claims 1 to 11, characterized by the fact that it comprises requesting, from the authentication authority, navigation keys to join said one or more cryptographic tokens protected by encryption and receiving said navigation keys through a secure communication channel.
[0013]
Method according to any one of claims 1 to 12, characterized in that said radio navigation signal receiver comprises a security perimeter in which part or all of steps a) to e) are performed.
[0014]
Radio navigation signal receiver, characterized by the fact that it is configured to perform the method as defined in any of claims 1 to 13.
[0015]
Method for verifying the authenticity of a data package, characterized by the fact that it comprises the steps of: receiving a data pack supposedly having been produced according to the method defined in any one of claims 1 to 13, said data pack including a first part containing positioning data and a second part containing a digital authentication code, said positioning data including the assumed time and geographical position; retrieving one or more cryptographic tokens that a radio navigation signal receiver would have received if it had actually been in the geographical position at that time; verify that the said positioning data and the digital authentication code are consistent with each other; and authenticate said data packet if said positioning data and digital authentication code are consistent with each other, or reject said data packet as invalid if said positioning data and digital authentication code are not consistent with each other.

类似技术:

---

公开号 | 公开日 | 专利标题

---

BR112012031598B1|2021-04-06|METHOD TO PROVIDE AUTHENTICABLE TIME AND LOCATION INDICATION, RADIO-NAVIGATION SIGNAL RECEIVER TO CONFIGURE THE SAME, AND METHOD OF CHECKING THE AUTHENTICITY OF A DATA PACKAGE

---

US10158492B2|2018-12-18|Blockchain-supported device location verification with digital signatures

---

USRE38899E1|2005-11-29|Method for providing location certificates

---

EP1329049B1|2005-12-14|Method and apparatus for real-time digital certification of electronic files and transactions using entropy factors

---

US20210273815A1|2021-09-02|Trusted Contextual Content

---

US9473510B2|2016-10-18|System and method for location verification

---

CN105492926A|2016-04-13|Digitally-signed satellite radio-navigation signals

---

EP2884689B1|2020-10-14|Random data from GNSS signals and secure random value provisioning for secure software component implementations

---

Kuseler et al.2012|Using geographical location as an authentication factor to enhance mCommerce applications on smartphones

---

US20220066045A1|2022-03-03|Secure global navigation satellite systems

---

US8800027B1|2014-08-05|Authentication using privacy protected personally identifiable information

---

CN104509068B|2018-07-20|Methods, devices and systems for improving data access control

---

Ceccato2019|Security in Global Navigation Satellite Systems: authentication, integrity protection and access control

---

WO2008142236A2|2008-11-27|Method for proving the occurrence of an event and/or the existence of a good in a given place and/or at a given time

---

Schielin et al.2012|On the Foundation of GNSS Authentication Mechanisms

同族专利:

---

公开号 | 公开日

---

RU2012141285A|2014-07-20|

---

KR101701912B1|2017-02-02|

---

ES2478876T3|2014-07-23|

---

US20130251150A1|2013-09-26|

---

CA2800193A1|2011-12-22|

---

RU2531384C2|2014-10-20|

---

NZ603704A|2014-07-25|

---

WO2011157554A1|2011-12-22|

---

US8948392B2|2015-02-03|

---

CN102933980A|2013-02-13|

---

KR20130097706A|2013-09-03|

---

MX2012013071A|2013-04-03|

---

JP5788976B2|2015-10-07|

---

EP2583117A1|2013-04-24|

---

CN102933980B|2014-12-10|

---

EP2397868A1|2011-12-21|

---

BR112012031598A2|2016-11-08|

---

EP2583117B1|2014-04-16|

---

AU2011267274A1|2012-12-20|

---

CA2800193C|2018-03-06|

---

JP2013534622A|2013-09-05|

---

AU2011267274B2|2015-02-05|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

JPS62114350A|1985-11-13|1987-05-26|Hitachi Ltd|Privacy system for remote sensing data|

---

US5134407A|1991-04-10|1992-07-28|Ashtech Telesis, Inc.|Global positioning system receiver digital processing technique|

---

US5754657A|1995-08-31|1998-05-19|Trimble Navigation Limited|Authentication of a message source|

---

US5757916A|1995-10-06|1998-05-26|International Series Research, Inc.|Method and apparatus for authenticating the location of remote users of networked computing systems|

---

US6446206B1|1998-04-01|2002-09-03|Microsoft Corporation|Method and system for access control of a message queue|

---

JPH11340962A|1998-05-25|1999-12-10|Hitachi Ltd|Key delivery method and device|

---

JP2000050193A|1998-07-27|2000-02-18|Fuji Photo Film Co Ltd|Method and device for generating digital image and storage medium|

---

JP2002016590A|2000-06-30|2002-01-18|Toyo Commun Equip Co Ltd|Encryption key delivery device and method|

---

US6583716B2|2001-08-15|2003-06-24|Motorola, Inc.|System and method for providing location-relevant services using stored location information|

---

JP2003115874A|2001-10-02|2003-04-18|Nippon Telegr & Teleph Corp <Ntt>|Method and device for distributing network news, network news distribution program and storage medium storing the same program|

---

JP4103465B2|2002-06-26|2008-06-18|ソニー株式会社|Information terminal device, information processing device, and information transmission / reception system|

---

JP2005157979A|2003-11-28|2005-06-16|Tdk Corp|Position authentication system and computer program|

---

JP2005265769A|2004-03-22|2005-09-29|Amano Corp|Positioning satellite monitoring system and location certification system of information processing device|

---

CN1930487A|2004-04-08|2007-03-14|三菱电机株式会社|Position guarantee server, position guarantee system, and position guarantee method|

---

WO2005107147A1|2004-04-28|2005-11-10|Hitachi, Ltd.|Authentication system, authentication acquisition device, and authentication method|

---

JP4237677B2|2004-06-02|2009-03-11|インターナショナル・ビジネス・マシーンズ・コーポレーション|Acquisition device, access control device, acquisition method, access control method, program, and recording medium|

---

JP2006267024A|2005-03-25|2006-10-05|Toshiba Corp|Position authentication system, position calculator, and program|

---

JP4644018B2|2005-03-31|2011-03-02|株式会社日立製作所|Location authentication method, mobile terminal and control station|

---

JP2006304193A|2005-04-25|2006-11-02|Toshiba Corp|Time and position authentication device, method, and program|

---

JP2008283235A|2007-05-08|2008-11-20|Something Holdings Co Ltd|Method of proving ground survey data, survey position, and survey time|

---

GB0712376D0|2007-06-26|2007-08-01|Nxp Bv|Processing of satellite navigation system signals|

---

CN201072441Y|2007-07-23|2008-06-11|深圳市远东华强导航定位有限公司石家庄分公司|Plate clip type navigation locating receiver|

---

EP2235690B1|2008-01-15|2018-07-18|Telit Automotive Solutions NV|Road toll system|

---

US8391488B2|2008-01-18|2013-03-05|Geocodex Llc|Method and apparatus for using navigation signal information for geoencryption to enhance security|

---

US20090195354A1|2008-02-02|2009-08-06|Peter Levin|Authenticating a signal based on an unknown component thereof|

---

US7969354B2|2008-02-02|2011-06-28|Zanio, Inc.|Authenticating a signal based on an unknown component thereof|

---

WO2009110471A1|2008-03-07|2009-09-11|株式会社日立製作所|Position information system|

---

FR2931336B1|2008-05-19|2011-02-11|Eads Secure Networks|METHODS AND DEVICES FOR TRANSMITTING AND AUTHENTICATING MESSAGES TO GUARANTEE THE AUTHENTICITY OF A SYSTEM|

---

KR101041157B1|2008-07-08|2011-06-13|삼성전자주식회사|Apparatus and method for sharing assistance data between a-gps teminal and gps teminal|

---

WO2010030825A1|2008-09-10|2010-03-18|Commlabs. Inc.|Wide area positioning system|

---

US8451840B2|2008-12-01|2013-05-28|Alcatel Lucent|Mobility in IP without mobile IP|

---

JP5493478B2|2009-06-03|2014-05-14|セイコーエプソン株式会社|Authentication system and authentication method|

---

JP5400529B2|2009-08-12|2014-01-29|株式会社日立情報制御ソリューションズ|Location information authentication method and location information authentication system using a secret encryption code|

---

EP2682785A1|2012-07-05|2014-01-08|Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V.|Concept for data authentication and secured localization based on a satellite navigation signal|

---

US8646060B1|2013-07-30|2014-02-04|Mourad Ben Ayed|Method for adaptive authentication using a mobile device|US7162035B1|2000-05-24|2007-01-09|Tracer Detection Technology Corp.|Authentication method and system|

---

US8171567B1|2002-09-04|2012-05-01|Tracer Detection Technology Corp.|Authentication method and system|

---

US8842834B2|2007-03-19|2014-09-23|Harris Corporation|Robust delivery of packet based secure voice|

---

US7995196B1|2008-04-23|2011-08-09|Tracer Detection Technology Corp.|Authentication method and system|

---

JP6029592B2|2011-11-19|2016-11-24|インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ|Storage device|

---

JP5667967B2|2011-12-20|2015-02-12|株式会社 日立産業制御ソリューションズ|Location information authentication system and location information authentication method|

---

CN103260160B|2012-05-07|2016-09-21|中国交通通信信息中心|RDSS user authen method based on satellite communications services|

---

CN103260157B|2012-05-07|2015-12-16|中国交通通信信息中心|Towards Subscriber Management System and the using method thereof of satellite communications services|

---

CN103260153B|2012-05-07|2015-07-15|中国交通通信信息中心|Satellite communication service system|

---

CN103259654B|2012-05-07|2016-06-29|中国交通通信信息中心|A kind of smart card administrative system based on satellite communications services|

---

FR2992069B1|2012-06-15|2016-11-18|Thales Sa|SATELLITE RADIO NAVIGATION SYSTEM WITH DEFINED ARCHITECTURE|

---

EP2680037A1|2012-06-27|2014-01-01|Astrium Limited|Authentication of satellite navigation signals|

---

EP2875653B1|2013-04-09|2016-06-29|Nec Corporation|Method for generating a dataset structure for location-based services|

---

US9507026B2|2013-05-04|2016-11-29|Trimble Navigation Limited|Apparatus for verified antispoofing navigation|

---

EP2806285B1|2013-05-24|2018-12-19|Nxp B.V.|A vehicle positioning system|

---

ITVI20130169A1|2013-07-01|2015-01-02|Qascom S R L|METHOD AND APPARATUS FOR THE AUTHENTICATION OF A SIGNAL OF SATELLITE NAVIGATION USING THE SIGNAL OF THE GALILEO COMMERCIAL SERVICE|

---

EP2824480A1|2013-07-09|2015-01-14|The European Union, represented by the European Commission|Digitally-signed satellite radio-navigation signals|

---

CN103439704B|2013-07-24|2015-05-13|中国西安卫星测控中心|Three-way observation data processing method based on virtual station|

---

US9606218B2|2013-07-26|2017-03-28|Here Global B.V.|Route verification from wireless networks|

---

CN103457932B|2013-08-15|2016-08-10|中电长城网际系统应用有限公司|A kind of cloud computing environment secure storage method of data and system|

---

US9395442B2|2013-10-08|2016-07-19|Motorola Solutions, Inc.|Method of and system for assisting a computer aided dispatch center operator with dispatching and/or locating public safety personnel|

---

US9094392B1|2013-10-28|2015-07-28|Rockwell Collins, Inc.|GNSS receiver autonomous signal authentication using signal stability analysis system and related method|

---

RU2560810C2|2013-11-01|2015-08-20|Илья Самуилович Рабинович|Method and system for protecting information from unauthorised use |

---

JP6269123B2|2014-02-06|2018-01-31|株式会社デンソー|Device with positioning function, positioning result receiving device, and positioning result utilization system|

---

JP6427889B2|2014-02-06|2018-11-28|株式会社デンソー|Navigation message authentication system, receiving terminal, and authentication processing device|

---

JP6379503B2|2014-02-06|2018-08-29|株式会社デンソー|Navigation message authentication type positioning device|

---

US10097951B2|2014-03-31|2018-10-09|Mcafee, Llc|Provable geo-location|

---

EP2930535A1|2014-04-08|2015-10-14|The European Union, represented by the European Commission|Method and system to optimise the authentication of radionavigation signals|

---

WO2015160001A1|2014-04-15|2015-10-22|Korea National University Of Transportation Industry-Academic Cooperation Foundation|Position authentication|

---

US20170090036A1|2014-06-18|2017-03-30|Continental Teves Ag & Co. Ohg|Method for verifying the plausibility of GNSS position signals|

---

CA2895520A1|2014-06-23|2015-12-23|Prabaharan Sivashanmugam|Systems and methods for authenticating user identities in networked computer systems|

---

DE102014213351A1|2014-07-09|2016-01-14|Siemens Aktiengesellschaft|Secured processing of a signal section of a received signal|

---

US10278069B2|2014-08-07|2019-04-30|Mobile Iron, Inc.|Device identification in service authorization|

---

US9635011B1|2014-08-27|2017-04-25|Jonetix Corporation|Encryption and decryption techniques using shuffle function|

---

US9923719B2|2014-12-09|2018-03-20|Cryptography Research, Inc.|Location aware cryptography|

---

WO2016091306A1|2014-12-10|2016-06-16|Here Global B.V.|Apparatus and associated method for providing u-turn guidance|

---

KR102336293B1|2014-12-19|2021-12-07|삼성전자 주식회사|Method and Device for controlling electronic device|

---

KR101677136B1|2015-05-27|2016-11-17|국방과학연구소|System and Method for Global Navigation Satellite System Spoofing Detection using a Single Authentic Signal|

---

USD812076S1|2015-06-14|2018-03-06|Google Llc|Display screen with graphical user interface for monitoring remote video camera|

---

USD803241S1|2015-06-14|2017-11-21|Google Inc.|Display screen with animated graphical user interface for an alert screen|

---

US10133443B2|2015-06-14|2018-11-20|Google Llc|Systems and methods for smart home automation using a multifunction status and entry point icon|

---

US9361011B1|2015-06-14|2016-06-07|Google Inc.|Methods and systems for presenting multiple live video feeds in a user interface|

---

GB2540536B|2015-06-24|2021-07-21|Nottingham Scient Limited|Method of testing a PNT configuration|

---

US10142296B2|2015-07-24|2018-11-27|Google Llc|Systems and methods for improving precision of a location sensor|

---

US9716697B2|2015-07-24|2017-07-25|Google Inc.|Generating bridge match identifiers for linking identifiers from server logs|

---

US10263779B2|2015-09-24|2019-04-16|Jonetix Corporation|Secure communications using loop-based authentication flow|

---

EP3165940A1|2015-11-04|2017-05-10|Nxp B.V.|Embedded communication authentication|

---

NL2016671B1|2016-04-25|2017-11-07|Fugro N V|GNSS Message Authentication.|

---

US10263802B2|2016-07-12|2019-04-16|Google Llc|Methods and devices for establishing connections with remote cameras|

---

USD882583S1|2016-07-12|2020-04-28|Google Llc|Display screen with graphical user interface|

---

USD843398S1|2016-10-26|2019-03-19|Google Llc|Display screen with graphical user interface for a timeline-video relationship presentation for alert events|

---

US11238290B2|2016-10-26|2022-02-01|Google Llc|Timeline-video relationship processing for alert events|

---

US10386999B2|2016-10-26|2019-08-20|Google Llc|Timeline-video relationship presentation for alert events|

---

EP3349044A1|2017-01-11|2018-07-18|The European Union, represented by the European Commission|Method and system for radionavigation authentication|

---

AU2018218371B2|2017-02-09|2021-05-20|The University Of Tokyo|Position information processing system and position information processing device|

---

CN106686597A|2017-03-17|2017-05-17|深圳丹勋科技有限公司|Method for using unmanned plane to recognize identity of mobile phone user in near field|

---

KR101991562B1|2017-04-14|2019-10-01|수상에스티|Device for transmitting position data packet and the method thereof|

---

KR102051704B1|2017-05-23|2020-01-08|수상에스티|Method for data encryption in a long range, lower rate data communications|

---

US10352496B2|2017-05-25|2019-07-16|Google Llc|Stand assembly for an electronic device providing multiple degrees of freedom and built-in cables|

---

US10972685B2|2017-05-25|2021-04-06|Google Llc|Video camera assembly having an IR reflector|

---

EP3410156A1|2017-06-02|2018-12-05|Nokia Technologies Oy|Positioning information verification|

---

US10698115B2|2017-06-27|2020-06-30|Here Global B.V.|Supporting an extended use of assistance data for Galileo|

---

US10694382B2|2017-06-27|2020-06-23|Here Global B.V.|Authentication of satellite navigation system receiver|

---

US10732288B2|2017-06-27|2020-08-04|Here Global B.V.|Enhanced use of satellite navigation system related data|

---

KR102004703B1|2017-06-30|2019-10-01|주식회사 엘핀|Location-based authentication apparatus and system using geofencing|

---

US10891366B1|2017-08-18|2021-01-12|Jonetix Corporation|Secure hardware signature and related methods and applications|

---

CN107864006A|2017-11-01|2018-03-30|千寻位置网络有限公司|Broadcast differential data authentication and the system and method for encryption|

---

WO2019124587A1|2017-12-21|2019-06-27|엘지전자|V2x communication device and secured communication method therefor|

---

US11074353B2|2018-06-20|2021-07-27|International Business Machines Corporation|Blockchain universal RFID translator|

---

US20200052896A1|2018-08-13|2020-02-13|Google Llc|Location-based access to controlled access resources|

---

US10752207B2|2018-09-07|2020-08-25|Ford Global Technologies, Llc|Multi-factor authentication of a hardware assembly|

---

KR102082975B1|2018-12-05|2020-02-28|한국항공우주연구원|Method and device for operation of fuse using satellite navigation apparatus|

法律状态:
2018-12-26| B06F| Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]|

---

2020-03-17| B15K| Others concerning applications: alteration of classification|Free format text: AS CLASSIFICACOES ANTERIORES ERAM: G01S 19/02 , G01S 1/04 , G01S 1/08 , G01S 19/09 Ipc: G01S 1/04 (2006.01), G01S 1/08 (2006.01), G01S 19/ |

---

2020-03-17| B06U| Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]|

---

2020-12-08| B09A| Decision: intention to grant [chapter 9.1 patent gazette]|

---

2021-01-26| B09W| Correction of the decision to grant [chapter 9.1.4 patent gazette]|Free format text: RETIFICACAO DO PARECER DE 9.1 |

---

2021-04-06| B16A| Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]|Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 31/05/2011, OBSERVADAS AS CONDICOES LEGAIS. |

优先权:

---

申请号 | 申请日 | 专利标题

---

EP10166025A|EP2397868A1|2010-06-15|2010-06-15|Method of providing an authenticable time-and-location indication|

---

EP10166025.6|2010-06-15|

---

PCT/EP2011/058989|WO2011157554A1|2010-06-15|2011-05-31|Method of providing an authenticable time-and-location indication|

---